Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix an ICE on an invalid binding @ ... in a tuple struct pattern #74557

Merged
merged 1 commit into from
Jul 21, 2020
Merged

Fix an ICE on an invalid binding @ ... in a tuple struct pattern #74557

merged 1 commit into from
Jul 21, 2020

Conversation

jakubadamw
Copy link
Contributor

Fixes #74539.

@rust-highfive
Copy link
Collaborator

r? @oli-obk

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 20, 2020
@jakubadamw
Copy link
Contributor Author

jakubadamw commented Jul 20, 2020

@JohnTitor, oh, I see in #74539 (comment) that you have a better idea than this? 🙂

@jakubadamw Great! You should tweak src/librustc_ast_lowering/pat.rs not losing diags.

What do you mean by “not losing diags”? The thing is that AST lowering runs after name resolution. 🤔 How else could it “poison” that particular invalid binding? Sorry, I don't know the compiler very well, it's been years. 🙂

@nagisa
Copy link
Member

nagisa commented Jul 20, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Jul 20, 2020

📌 Commit db77a9e516ad37a730c19e3c008c7279b5767aa7 has been approved by nagisa

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 20, 2020
@nagisa nagisa added stable-nominated Nominated for backporting to the compiler in the stable channel. beta-nominated Nominated for backporting to the compiler in the beta channel. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 20, 2020
let e = E::A(2, 3);
match e {
E::A(x @ ..) => { //~ ERROR `x @` is not allowed in a tuple
x //~ ERROR cannot find value `x` in this scope
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, x should be found here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JohnTitor, this is a consequence of the nature of the fix. But I think you're right, this should be done differently.

@jakubadamw
Copy link
Contributor Author

jakubadamw commented Jul 20, 2020

@JohnTitor, okay, I have now pushed a second commit with an alternate, simpler approach. But it leads to diagnostics that are, in my opinion, degraded compared to the status quo.

error: `x @` is not allowed in a tuple struct
  --> $DIR/issue-74539.rs:9:13
   |
LL |             x @ ..
   |             ^^^^^^ this is only allowed in slice patterns
   |
   = help: remove this and bind each tuple field independently
help: if you don't need to use the contents of x, discard the tuple's remaining fields
   |
LL |             ..
   |             ^^

error: `..` patterns are not allowed here
  --> $DIR/issue-74539.rs:9:17
   |
LL |             x @ ..
   |                 ^^
   |
   = note: only allowed in tuple, tuple struct, and slice patterns

error[E0023]: this pattern has 1 field, but the corresponding tuple variant has 2 fields
  --> $DIR/issue-74539.rs:8:9
   |
LL |       A(u8, u8),
   |       --------- tuple variant defined here
...
LL | /         E::A(
LL | |             x @ ..
LL | |         ) => { x }
   | |_________^ expected 2 fields, found 1

error: aborting due to 3 previous errors

For more information about this error, try `rustc --explain E0023`.

We end up with two extra diagnostics that do not contribute anything new.

Which solution seems better in your opinion?

@JohnTitor
Copy link
Member

@jakubadamw Thanks for investigating more! I like the later diagnostics but let's hear opinion from @nagisa or someone from T-compiler.

@nagisa
Copy link
Member

nagisa commented Jul 20, 2020

I personally like the former slightly more because its not as redundant (and x not being found is fine given that its a variable introduced by an error), but ultimately either error seems fine to me as either approach fixes the significantly more important problem – the ICE.

In the end the decision on diagnostics is something that @rust-lang/wg-diagnostics is responsible for and the diagnostics themselves can be iterated further in a separate PR that does not target a backport to beta or stable. If we want this to be backportable it needs to be as simple and obviously correct as it can possibly get.

@jakubadamw
Copy link
Contributor Author

@nagisa, thank you. Looks like I stepped on your toes by pushing after your r+, sorry! 🙂 Yeah, I agree the first solution gives nicer results (although implementation wise it's not as simple as the second one). Should we await input from @rust-lang/wg-diagnostics or go ahead with the first approach? If the latter, then I can take back the redundant commits.

src/librustc_ast_lowering/pat.rs Outdated Show resolved Hide resolved
@jakubadamw
Copy link
Contributor Author

@nagisa, okay, I brought back the initial version. 🙂

@nagisa
Copy link
Member

nagisa commented Jul 20, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Jul 20, 2020

📌 Commit 77a2fbb86e9a0cddc18722390d939e9bcd874c64 has been approved by nagisa

@jakubadamw
Copy link
Contributor Author

@nagisa, pardon, this will need one more r+, as I had to tidy up the style per the failed build. 🙂

@davidtwco
Copy link
Member

@bors r=nagisa

@bors
Copy link
Contributor

bors commented Jul 20, 2020

📌 Commit f5e5eb6 has been approved by nagisa

Comment on lines +1509 to +1513
// In tuple struct patterns ignore the invalid `ident @ ...`.
// It will be handled as an error by the AST lowering.
PatKind::Ident(bmode, ident, ref sub)
if !(is_tuple_struct_pat && sub.as_ref().filter(|p| p.is_rest()).is_some()) =>
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR can be merged as is, but I think we could also add another branch that detects the case with PatKind::Ident(..) where .. is present and record it with a PartialRes::new(Res::Err), which should eliminate the second unnecessary error that complains about x not being defined. (Haven't looked at this deeply enough to be sure.)

bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 20, 2020
…arth

Rollup of 13 pull requests

Successful merges:

 - rust-lang#72714 (Fix debug assertion in typeck)
 - rust-lang#73197 (Impl Default for ranges)
 - rust-lang#73323 (wf: check foreign fn decls for well-formedness)
 - rust-lang#74051 (disallow non-static lifetimes in const generics)
 - rust-lang#74376 (test caching opt_const_param_of on disc)
 - rust-lang#74501 (Ayu theme: Use different background color for Run button)
 - rust-lang#74505 (Fix search input focus in ayu theme)
 - rust-lang#74522 (Update sanitizer docs)
 - rust-lang#74546 (Fix duplicate maybe_uninit_extra attribute)
 - rust-lang#74552 (Stabilize TAU constant.)
 - rust-lang#74555 (Improve "important traits" popup display on mobile)
 - rust-lang#74557 (Fix an ICE on an invalid `binding @ ...` in a tuple struct pattern)
 - rust-lang#74561 (update backtrace-rs)

Failed merges:

r? @ghost
@pnkfelix
Copy link
Member

The beta nomination was discussed at weekly T-compiler meeting.

The stable nomination was also discussed at that same meeting.

At the end of both discussions, I noted (and @Mark-Simulacrum agreed) that we'd be more comfortable backporting this if it guarded against the scenario where this guard fires but the AST-lowering code, for whatever reason, doesn't signal an error.

In particular, we think that should be implementable via a delay_span_bug invocation.

Having said that, adding a delay_span_bug invocation is not a strict prerequisite for the backport; it is merely something we see as a "nice to have" since it would give us confidence that this change cannot cause a miscompilation down the road.

Having said that: beta backport approved, and stable backport approved.

@pnkfelix pnkfelix added beta-accepted Accepted for backporting to the compiler in the beta channel. stable-accepted Accepted for backporting to the compiler in the stable channel. labels Jul 23, 2020
@Mark-Simulacrum Mark-Simulacrum removed the stable-nominated Nominated for backporting to the compiler in the stable channel. label Jul 23, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Jul 24, 2020
delay_span_bug instead of silent ignore

This is a follow-up to rust-lang#74557.

r? @pnkfelix
Manishearth added a commit to Manishearth/rust that referenced this pull request Jul 24, 2020
delay_span_bug instead of silent ignore

This is a follow-up to rust-lang#74557.

r? @pnkfelix
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 2, 2020
Fix ICEs with `@ ..` binding

This reverts rust-lang#74557 and introduces an alternative fix while ensuring that rust-lang#74954 is not broken.
The diagnostics are verbose though, it fixes three related issues.
cc rust-lang#74954, rust-lang#74539, and rust-lang#74702
@cuviper
Copy link
Member

cuviper commented Aug 4, 2020

I've removed the beta backport labels. This was already backported to stable for 1.45.1, then reverted in 1.45.2 due to #74954. We'll let this release naturally with the follow-up fix in #74963.

@cuviper cuviper removed beta-accepted Accepted for backporting to the compiler in the beta channel. beta-nominated Nominated for backporting to the compiler in the beta channel. labels Aug 4, 2020
@cuviper cuviper added this to the 1.47.0 milestone May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. stable-accepted Accepted for backporting to the compiler in the stable channel. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ICE with the @ .. binding pattern